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We present a prototype that implements a set of logical rules to prove the satisfiability for a class of 
specifications on XML documents. Specifications are given by means of constrains built on Boolean 
XPath patterns. The main goal of this tool is to test whether a given specification is satisfiable or 
not, and justify the decision showing the execution history. It can also be used to test whether a 
given document is a model of a given specification and, as a by-product, it permits to look for all 
the relations (monomorphisms) between two patterns and to combine patterns in different ways. The 
results of these operations are visually shown and therefore the tool makes these operations more 
understandable. The implementation of the algorithm has been written in Prolog but the prototype 
has a Java interface for an easy and friendly use. In this paper we show how to use this interface in 
order to test all the desired properties. 


1 Introduction 

Our aim is to define specifications of XML documents as sets of constraints (of some specific class) on 
these documents, and to provide a form of reasoning about these specifications. XML documents will be 
represented by trees and the constraints will be based on some kind of XPath queries ll8l|3l|2l. 

To define the constraints on some XPath notation, we have selected the representation of Boolean 
XPath queries given in ||5l, where Miklau and Suciu study the containment and equivalence problems 
for a class of XPath queries that contain branching and label wildcards and can express descendant rela¬ 
tionships between nodes. In particular, they introduce Boolean patterns as an alternative representation 
of this class of queries. These patterns are trees consisting of nodes with labels (or *, for a wildcard in 
the query) and two kinds of edges, child edges (/) and descendant edges (//), for the corresponding axes 
in the query. For instance, the pattern p in Figure [T] (on the left) corresponds to the XPath expression 
/a[b] [.// * [e] [cf]]. We define three sorts of constraints (positive, negative, and conditional constraints) on 
these patterns. A specification is defined as a set of clauses, where a clause is a disjunction of constraints. 

Our main question is about satisfiability, that is, given a specification whether or not there exists 
an XML document satisfying all constraints in Moreover, we are looking for adequate inference rules 
to build a sound and complete refutation procedure for checking satisfiability of a given specification. 
In addition to checking satisfiability, these rules would be used to deduce other constraints, which can 
permit us to optimize a satisfiable specification. 

Our approach follows the main ideas given in [71 (here it is shown how to use graph constraints 
as a specification formalism on graphs and how to reason about these specifications, providing refuta¬ 
tion procedures based on inference rules that are sound and complete) and try to apply such ideas to 
XML documents. However, the particularization of graph constraints to our setting is not trivial (mainly 
because our patterns are more expressive). Similarly, our inference rules take a similar format to the 
inference rules given in Q, but the particularization to our setting needs to define appropriate operators 
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and to prove new results. The formal study of our work is now submitted for presentation, but the ideas 
and preliminaries of such work were introduced in Q. 

In this paper we focus on the prototype that implements our refutation procedure. The algorithm is 
written in Prolog 0 but also has a Java interface for an easy and friendly use. The main goal of this tool 
is to test whether a given specification is satisfiable or not, and justify the decision by showing the rules 
applied during the procedure execution. It can also be used to test whether a given document is a model 
of a given specification and, as a by-product, it permits to look for all the monomorphisms between 
two patterns or to look for the result of doing the operations p^q and p ®c,m q which are necessary for 
implementing some rules. The results of these operations are visually shown and therefore it makes them 
more understandable. 

The paper is organized as follows. There are two main sections, the first one dedicated to the formal 
background and the second one to show the prototype. Section starts by introducing the formal defi¬ 


nitions of document, pattern, and the relations (monomorphisms) between them. Then, in Section 2.1 


we present the constraints and clauses that we are going to use to define our specifications and, in fhe 
Secfion|2^ fhe main inference rules for our refulafion procedure. The profofype is presenfed in Section 
where we explain how fo perform several operations by means of examples and by showing differenl 
screenshofs of fhe fool. Finally, in Secfion|^ we give some nofes on implemenfafion and some commenfs 
abouf fhe ongoing work for obfaining complefeness for our refulafion procedure. 


2 Formal Background 

We consider an XML document as an unordered and unranked free wilh nodes labelled from an infinite 
alphabef £. The symbols in £ can represenl fhe elemenf labels, affribule labels, and lexl values lhal can 
occur in XML documenls. Nofe lhaf fhis is an abslracf represenfalion of a real XML documenl since we 
are only inleresled in ils free slruclure. Figure [T] shows a documenl t (on fhe righl) wilh roof labelled a 
and Iwo sublrees. Here is fhe formal definilion of documenl. 

Definition 2.1 Given a signature £, a documenl on £ is a tree t whose nodes are labelled with symbols 
from £ and with one sort of edges denoted/. Nodes{t) and Edgesf) denote respectively the sets of nodes 
and edges in t; Root{t) denotes its root node; and for each n G Nodesf), Label{n) denotes the label of 
such a node n. Each edge in Edge{t) is represented {x,y) with x,y G Nodesf). Each {x,y) G Edges^f) 
represents a path in t from node x to node y. 

As said in fhe inlroduclion, we use palfems as an alfemalive represenfalion of Boolean queries. 
Palfems will be also represenled as some sorl of frees buf wilh Iwo differences wilh respecl lo documenls. 
Some edges in paflerns can be double (//) and if is permitted fhe label * in nodes. Figure[T]shows a pattern 
p (on fhe lefl) lhal has a label * in a node and an edge // from fhe roof a info one of ils children. 

A pattern specifies fhe condifions lhal a documenl musl hold. For inslance, Ihe pattern p in Figure [T] 
specifies Ihe following conditions: “The roof of Ihe documenl musl be a node labelled a, one of ils child 
nodes musl be a node labelled b, and a descendanl node of Ihe roof musl have (al leasl) Iwo children 
labelled e and d”. Here is Ihe formal definition of pattern. 

Definition 2.2 Given a signature £, a pattern on £ is a tree p whose nodes are labelled with symbols 
from £U {*} and with two sorts of edges: the descendant edges denoted//, and the child edges denoted/. 
Nodes{p), Edges{p), Root{p), and Label{n) are defined as in the previous definition; but now the edges 
are distinguished: Edges{p) = Edges^{p)UEdges^{p), therefore (x,y) G Edges^{p) represents a path 
in p from node x to node y with edges of type / or//along the path. 
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Figure 1: A monomorphism h: p —?■ t from a pattern p to a document t 


To define when a document satisfies a given pattern we use the notion of homomorphism. As doc¬ 
uments are patterns without labels * or edges //, we define here the notion of homomorphism between 
two patterns and, as a consequence, the definition of homomorphism from a pattern into a document is a 
particular case. 

Definition 2.3 Given two patterns p and q, a homomorphism/rom p into q is a function h : Nodes(p) —?■ 
Nodes{q) satisfying the following conditions: 

• Root-preserving: h{Root{p)) =Root{q); 

• Label-preserving: For each n £ Nodes{p), Label{n) = * or Label{n) = Label{h{n)); 

• Child-edge-preserving: For each {x,y) £ Edges^{p), {h{x),h{y)) £ Edgesi{q). 

• Descendant-edge-preserving: Eor each {x,y) £ Edgesjj{p), {h{x),h{y)) £ Edges^{q). 

Note that the “child-edge-preserving” condition says that each edge / in a pattern p must be applied 
into an edge / in the pattern q and the “descendant-edge-preserving” condition says that each edge // in a 
pattern p can be applied into a path in q (with one or more edges of type / or // along the path). 

In the particular case when g is a document, the last condition applies each edge // in the pattern p 
into a path in the document q (with one or more edges / along the path). 

Definition 2.4 Given a pattern p and a document t, we say that t satisfies p, denoted t\= p, if there exists 
a monomorphism (i.e, an injective homomorphism) from p into t. The model set of a pattern p is the set 
of documents satisfying p: Mod{p) = {t \ i 1= p}. 

In Figure[T]there is a pattern p (on the left), a document t (on the right) and a monomorphism h: p^t 
(which is drawn with dotted arrows). Then t satisfies (or is a model of) p. We can see thaf in fact the 
root of the document f is a node labelled a, one of its child nodes is a node labelled b, and a descendant 
node of the root (in this document the node labelled /) has two children labelled e and d. It corresponds 
to evaluate the XPath expression / = /a[b\ [.// * [e] [r/]] against the document t. 

2.1 Specifications 

We assume that a specification consists of a set (or conjunction) of clauses, where a clause is a disjunc¬ 
tion of constraints (the empty disjunction is the clause EALSE). Now we introduce the three kinds of 
constraints we are going to use: positive, negative, and conditional constraints. A positive constraint 
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specifies that a pattern must be satisfied and a negative constraint specifies that the pattern must not be 
satisfied. A conditional constraint consists of two patterns, p and q, such that q is an extension of p. 
Roughly speaking, this constraint specifies that whenever a document t verifies the pattern p it should 
also verify the extended pattern q (see Definition |2.7| ). 

Definition 2.5 Given two patterns p and q, we say that p is a prefix of q if there exists an injective 
function (called prefix functionj c : Nodes{p) — Nodes{q) satisfying the following conditions: 

• Root-identity: c{Root{p)) =Root{q); 

• Label-identity: For each n € Nodesi^p), Label{n) = Label{c{n)); 

• Child-edge-identity: For each {x,y) ^ Edgesj{p), (c(x),c(y)) ^ Edgesi{q); 

• Descendent-edge-identity: Eor each {x,y) £ Edgesjj{p), (c(x),c(y)) £ Edgesjj{q). 

Definition 2.6 Given a pattern p, 3p denotes a positive constraint and -<3p denotes a negative con¬ 
straint. A conditional constraint is denoted V(c : p ^ q) where p and q are patterns, p is a prefix of q 
with c : Nodes{p) —)• Nodes{q) being the prefix function. 

The satisfaction of clauses is defined inductively as follows. 

Definition 2.7 A document t satisfies a clause ot, denoted t \= a, if it holds: 

• t \=3p ift 1= p (that is, if there exists a monomorphism h: p ^ t); 

• t \= ^3p if t p (that is, if there does not exist a monomorphism h: p ^ t); 

• f 1= V(c : p — 7 - ( 7 ) if for every monom. h : p ^ t there is a monom. f : q ^ t such that h = f oc. 

• t \= L\ V L 2 V .. .V L„ if t \= Li for some / G {1,..., n}. 

Let us see now an example of a conditional pattern. Let p be the pattern corresponding to the XPath 
expression /a[./ /e] (that is, the tree root is labelled a and the child node is labelled e with an edge // 
between both nodes) and let q be the pattern corresponding to the XPath expression /a[.//e[f]] (that is, 
the tree extending p by adding a node labelled / as a child node of e with an edge / between them). 
The document t in Figure (on the right) does not satisfy the constraint \/{c : p ^ q) (where c is the 
prefix function applying p into q) since not all descendant nodes labelled e int have a child labelled /. 
However the document t satisfies the pattern q. Note that in general to verify the conditional constraint 
V(c : p —)• ^) is stronger than to verify the clause C = -iBp V 3q. 


2.2 Inference Rules for a Refutation Procedure 

A refutation procedure for a specification can be seen as a sequence of inferences 
^ hoi ^ . where the initial state is the original specification (i.e., '^0 = and each '^■+1 is obtained 

from % by applying a rule. The main inference rules of our refutation procedure are the following: 


BpiVFi -i3p2Vr2 

Fi vr2 


(Rl) 


if there exists a monomorphism m : p 2 —)• pi 


Rule (Rl) is like a resolution rule, since the two premises have literals that are, in some sense, “com¬ 
plementary”: one is a positive constraint, the other one is a negative one, and the condition about the 
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monomorphism from p 2 to pi plays the same role as unification. Note that when Fi and r 2 are empty, 
the rule (Rl) infers the clause FALSE. 


BpiVFi 3p2Vr2 
(V.epi®P2 3^)vrivr2 


(R2) 


Rule (R2) builds a disjunction of positive constraints from two positive constraints. It uses the operator 
® that we define below. Informally speaking, p\®p 2 denofes fhe sef of paffems fhaf can be obfained by 
“combining” pi and p 2 in all possible ways. 


apiVFi V(c:p2-^<?)vr2 

if fhere is a monomorphism m\ p 2 ^ p\ thaf cannof be extended to f ■. p\ such fhaf f oc = m. 


Rule (R3) is similar fo rule (R2): From a positive consfrainf 3p\ and a conditional consfrainf V(c : 
P 2 ^ it builds a disjunction of positive consfrainfs. If uses fhe operator ®c,m thaf we define below. 
Informally speaking, pi ®c,m <7 denofes fhe sef of paffems fhaf can be obfained by combining pi and q in 
all possible ways, buf mainfaining p 2 shared. 

Definition 2.8 Given two patterns pi and p 2 , p\ ® P 2 is the following set of patterns: p\® P 2 = {s \ 
there exist jointly surjective monomorphisms inci pi ^ s and inc 2 : P 2 ^ sj . 

Definition 2.9 Given two patterns pi, p 2 , a prefix function c : p 2 ^ q, and a mononiorphism m: p 2 ^ pi, 
Pi ®c,m<i is the following set of patterns: pi ®c,m^ = | there exist jointly surjective monomorphisms 

inci : Pi —)• 5 and inc 2 : q ^ s such that inc\ om- inc 2 oc}. 

We have formally proven that the refutation procedure consisting of the three inference rules (Rl), 
(R2), and (R3) is sound |i6j. That is, whenever the procedure infers the clause FALSE from a input set 
of clauses 5^, then is unsatisfiable. The prototype we explain in the next section implements this 
refutation procedure when we choose to execute “Version 1”. Moreover, the refutation procedure also 
uses sound rules for deleting and simplifying clauses and the implementation applies them as soon as 
possible to get a better performance. To sum up, given a specification as input, if the result of running 
“Version 1” is that the procedure stops with FALSE, then we are sure that the specification is unsatisfiable. 

However, the procedure is not complete: It may happen that the clause FALSE is not inferred although 
5^ is unsatisfiable (see |j6|). Looking for a complete procedure, we have studied how to transform a pos¬ 
itive constraint containing a descendant edge (//) into a (semantically equivalent) disjunction of positive 
constraints, in order to apply inference rules that could not be applied before such transformation. We 
call it “the unfolding process” and have incorporated it into the refutation procedure. Some preliminary 
details of this study can be found in fTj and a preliminary refutation procedure obtained by adding this 
“unfolding process” has been implemented and can be tested running “Version 2” of the prototype. Al¬ 
though we are still working on a formal proof, we believe that the new procedure is complete. This 
would mean that if the input specification is unsatisfiable then the procedure stops and returns FALSE. 

Finally, we must observe that for satisfiable specifications, the procedure can stop (without obtaining 
the clause FALSE) or not stop. We are studying the causes of non-termination and we would like to 
obtain that our procedure does not stop only in the case of satisfiable specifications whose models are all 
infinite. Such specifications are possible due to the conditional constraints. If we restrict to specifications 
with only positive and negative constraints, the refutation procedure is finite. 
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3 Showing the Prototype 

In this section we explain how to use the application. In particular, introducing the clauses, executing the 
refutation procedure, testing whether a document is a model of a specification, and other operations that 
can be visually executed. 



Figure 2: Home screen of the application 


3.1 Introducing Clauses 

The Home screen of the application consists of three different panels, besides the menu bar: the clauses’ 
panel, the constraints’ panel, and the pattern editor. In order to create a clause, click on the “Edit” button 
of “New Clause”. After that, the constraints’ panel will show the selected clause’s constraints. Since 
the clause is new, it will only appear the option of creating a new constraint. By clicking on the “Edit” 
button of “New Constraint”, the pattern editor will be shown, as it can be noticed in Eigure]^ The type 
of constraint (3, -iBjV) is indicated by clicking on one of the upper buttons. Then, build the pattern by 
using the nodes, children edges (/), and descendant edges (//) creation buttons. 

If the selected constraint is conditional, V(c : p —)• < 7 ) , the editor screen will change into the one in 
Eigure where p must be drawn on the upper left box and q on the upper right box. Once they are set, 
click on the “Generate pre-tree” button and the system will find all fhe prefix funcfions fhaf exisf befween 
the two patterns. Click on the arrow-form buttons to choose the correct function and click on “Accept”. 

Once we have drawn all constraints of all clauses, we can save this specification by selecting the 
option “Save” or “Save as” from the “Eile” menu. It is saved with a name and extension “.spec”. 

It is also possible to load an existing specification (that was previously saved) by selecting the option 
“Open” from the “Eile” menu. 

3.2 Executing the Refutation Procedure 

Once all the clauses have been created, let us see how to run the refutation procedure. To do so, pick 
one of the two versions from the “Execute” menu, as it is shown in Eigure As said before, when 
we choose to run “Version 1”, the procedure consists of the three inference rules (Rl), (R2), and (R3) 
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Figure 3: Editor for conditional constraints 


together with some rules for deleting and simplifying clauses. After finishing the procedure (if it stops), 
a message is displayed in which appears the satisfiability result of the input specification and the elapsed 
time (see Figure [^. If this result is FALSE then we have proven that the specification is unsatisfiable. If 
it stops without obtaining FALSE, then we cannot affirm fhaf fhe specificafion is safisfiable because fhe 
procedure is nof complefe. If we choose fo run “Version 2”, fhis procedure adds some rules fo perform fhe 
previously menfioned “unfolding process”. By using fhis new procedure, we can prove unsafisfiabilify 
in more specificafions fhan wifh fhe “Version 1” procedure, buf for now if is an ongoing work. 

The execution history will be automatically opened in ofher window. This history is very useful fo see 
fhe rules used fo obfain FALSE. In fhis new screen (shown in Figure [^, besides fhe history, if is possible 
fo consulf clauses and constrainfs. Enfer fhe identifier of a clause (e.g. c4) in fhe clause searching area 
and if will be shown. The consfrainf search works exactly like the clause search, but with constraint 
identifiers (e.g. cfl). The upper righf buffon loads every existing clause and displays fhem. Also, wifh 
the “See clauses” buttons, it is possible to consult specific clauses from fhe differenf sfeps of fhe history. 
For insfance, if we click on fhe buffon of fhe second step in Figure]^ fhe system will load fhe clauses cl, 
c2, and c5. Finally, fo export fhe history to a text file, click on fhe save buffon on fhe upper leff corner. 
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Figure 4: Menu for executing the procedure 



Figure 5: The result of the procedure 


3.3 Document Checking 

Another important aim of this application is to check whether a given document satisfies a given spec¬ 
ification or not. For that, click on “Check specification” in the “Tools” menu (see Figure |^. This 
operation will open a window, similar to the Home screen, where the clauses of the specification and the 
XML document will be introduced. The application also allows one to copy the set of clauses from the 
Home screen to this window. For that, click on “Check current specification” in the “Tools” menu (see 
Figure [^. After being copied, new clauses can be introduced or existing ones can be deleted without 
compromising the original ones. In this case, the XML document must be introduced too. 

After introducing the XML document by clicking on the “Accept” button, and once loaded the spec¬ 
ification by any of the two possible ways, click on the “Check” button (see Figure and a message with 
the result will be shown. The message will be TRUE when the document is a model of the specification, 
and FALSE otherwise. In the later case, we probably want to check which are the clauses that the docu¬ 
ment satisfies and which are not. Clauses can be deleted temporarily from the specification by clicking 
on its “Delete” button to do these tests and they can be later restored by clicking on its “Restore” button 
(see Figure]^. 


3.4 Other Tools 

Throughout the refutation process three basic operations are continuosly used: monomorphism from p 
into q, the operation pi 0 pi in rule (R2), and the operation pi in rule (R3). The application 

includes tools to execute such operations visually called Monomorphism, Join, and Shared join, respec¬ 
tively. 

























J. Albors, M. Navarro 


35 



Figure 6: History of the procedure 
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Figure 7: Document checking option 


3.4.1 Monomorphism 

When selecting “Monomorphism” from the “Tools” menu, a new screen will appear, very similar to 
the one for creating a conditional constraint. Provided that we want to find out whether there exists a 
monomorphism from p into q, we introduce the pattern p into the upper left box and the pattern q into the 
right box. Then, click on “Generate monomorphism” and the system will find every possible solution. 
For instance in the Figure [T^ it is shown one of the four monomorphisms existing from p into q. The 
other three solutions can be consulted by clicking on the arrow-form buttons. 


3.4.2 Join operation {p\ ® p 2 ) 

The “Join” tool will also open a similar window to the conditional constraint screen. We will introduce 
the patterns we want to operate, pi and p 2 , into the two upper editors. After that, we click on the “Join” 
button and the solution will be calculated. On the lower editor will appear a set of patterns s\,S 2 ,...,Sn 
which express the different ways of “combining” pi and p 2 (see Figure [TT]). Recall this operation is used 
in rule (R2) to obtain {Msepi^pi ^^ 2 - 
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Figure 8: Document checking against a specification 



Figure 9: Document checking against some clauses in a specification 


3.4.3 Shared join operation (p i <S)c,m q) 

Similarly, the operation p\ ®c,mq is used in rule (R3) to obtain {\/from the constraints 3pi 
and V(c : p 2 ^ q)- Since one of them is a conditional constraint, the tool is comprised by two windows. 
In the first one, we will introduce the conditional constraint as shown in Figure]^ and, after clicking on 
the “Next” button, this conditional constraint appears on the upper left box of the second window (see 
Figure [T^; whereas the positive constraint is introduced into the upper right box. Then, we click on 
“Shared join” and in the lower editor will appear a set of patterns s\,S 2 ,...,Sn which express the different 
ways of “combining” p\ and q by considering the morphism m from p 2 to pi. Due to the possibility of 
having more than one monomorphism from p 2 to p\ (that cannot be extended to a monomorphism from 
^ to pi), different solutions will be shown. We can change the solution by clicking on the arrow-form 
buttons. 
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Figure 10: Monomorphism 


4 Implementation Notes 

The prototype implementing the previously deseribed refutation procedure is available at http: / / 
WWW .sc.ehu.es/jiwnagom/PaginaWebLorea/SpecSatisf iabilityTool .html, where 
we also explain the application’s requirements and the configuration of the Java-Prolog bridge. The code 
of this application consists of around 1300 Prolog lines (in SWI-Prolog version 6.0.2) for the refutation 
procedure and around 4000 Java lines (in Java version jre7) for the interface. 

Now, we roughly explain the algorithms designed in each version of the refutation procedure. See 
iTj for more details about the implementation or for a user guide of the application. 

4.1 Version 1 algorithm 

We give here the idea of the algorithm implementing this refutation procedure. We start with the initial 
specification Sq. Clause by clause and constraint by constraint the procedure applies every possible infer¬ 
ence rule (Rl), (R2), or (R3) obtaining a set Sq of new clauses. Now the system divides the application 
of the rules in two parts: first, it applies every possible rule between two clauses, but being one from So 
and the other one from the new set Sq. After finishing fhis parf, if applies every possible rule among fhe 
clauses in Sq. In fhis way, all fhe clauses (resolvenfs) produced by applying fhese rules on Si = So USq 
are in a new sef Sj. This process will be repealed unlil fhe clause FALSE comes ouf or until no rule can 
be applied. 

As said above, ofher rules for deleting and simplifying clauses are also applied (as soon as possible) 
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Figure 11: Join operation pi® p 2 
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Figure 12: Shared join operation p\®c,m(l 
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in order to get a better performance. In particular, each time a new clause is produced by an inference 
rule, the procedure tries to simplify or delete this clause or another one related to this one. For instance, a 
clause like Fi V r 2 can be deleted from the set of clauses if the clause Fi is produced as a resolvent (and 
therefore it is added to the set), since the latter one subsumes the first one. On the other hand, a clause 
containing two equal literals can be simplified by delefing one of them in the clause. 

By using all these rules, the inference rules (Rl), (R2), and (R3), and the rules for deleting and 
simplifying clauses, the input specification and each specification S, obtained during this process are 
logically equivalent. Therefore, given a specification as input, if the result of running “Version 1” is that 
the procedure stops with FALSE, then the specification is unsatisfiable. Otherwise (if it does not stop or 
if it stops without obtaining FALSE) then we cannot give any answer about the specification satisfiability. 

4.2 Version 2 algorithm 

This version is an ongoing work. The actual algorithm is as follows: It starts by calling to the Version 
1. Then, if the result returns the clause FALSE, it finishes (since it has been proven that the input speci¬ 
fication is unsatisfiable). If Version I finishes returning TRUE, then the “unfolding process” is done. If 
this process does not obtain new clauses, the algorithm finishes with the result of TRUE, meaning that 
the input specification is satisfiable. But if the “unfolding process” obtains a new set of clauses, then the 
whole procedure (“version 1” -i- “unfolding process”) is repeated with this new set of clauses as input 
specification. 

Apart of trying to prove the completeness of the algorithm (as said previously), we are also testing the 
actual implementation. Some problems with non-term!nation due to rule (R3) and the fairness property 
must still be fixed (a procedure is fair whenever no inference rule is posfponed forever). Nevertheless, 
for some specification examples, we can prove that they are unsatisfiable by running “version 2” while 
they cannot be proven running “version 1”. 
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